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STANDARD FORMAT SPECIFICATION FOR AUTOMATICALLY 
CONFIGURING IP SECURITY TUNNELS 

BACKGROUND OF THE INVENTION 

5 

1. Technical Field: 

The present invention relates in general to a method 
and system for securing networks. Still more 
particularly, the present invention relates to an 
10 improved system and method for providing a standard 

format to use to configure IP security tunnels where the 
standard format may be used by any one of multiple, 
different operating systems and multiple, different 
machine types. 

15 

2. Description of Related Art: 

In today's modern environment, many businesses and 
organizations deal with global markets and have global 
logistic concerns. Many organizations have facilities 

20 disbursed across the country or even around the world. 

Despite their global presence, these organizations need a 
way to maintain fast, secure and reliable communications 
with individuals and other offices throughout the world. 
Until recently, fast, secure and reliable 

25 communication has meant the use of leased lines to 
maintain a Wide Area Network (WAN) . Leased lines, 
ranging from ISDN (Integrated Services Digital Network, 
144 Kbps) to 0C3 (Optical Carrier-3, 155 Mbps) fiber, 
provided a company with a way to expand their private 

30 network beyond their immediate geographic area. A WAN had 
obvious advantages over a public network like the 
Internet when it came to reliability, performance and 
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security. But maintaining a WAN, particularly when using 
leased lines, can become quite expensive and often rises 
in cost as the distance between the offices increases. 
In addition, using WANs is not a scaleable solution as 
5 the number of interconnections rises exponentially as new 
locations are added. 

In essence, a Virtual Private Network, or "VPN," is 
a private network that uses a public network (usually the 
Internet) to connect remote sites or users together. To 

10 make communication between computers private, VPNs use 
security methods, such as encryption, to maintain 
privacy. Instead of using a dedicated, real-world 
connection such as a leased line, a VPN uses "virtual" 
connections routed through the Internet from the 

15 company's private network to the remote site or employee. 

A well-designed VPN can greatly benefit a company. 
For example, it can: extend geographic connectivity, 
improve security, reduce operational costs versus 
traditional WAN, reduce transit time and transportation 

20 costs for remote users, improve productivity, simplify 
network topology, provide global networking 
opportunities, provide telecommuter support, provide 
broadband networking compatibility, and provide faster 
ROI (Return On Investment) than traditional WAN. A 

25 well-designed VPN, therefore, should incorporate features 
for security, reliability, scalability, network 
management, and policy management. 

In a VPN, each remote member of the network is able 
to communicate in a secure and reliable manner using the 

30 Internet as the medium to connect to a private local area 
network, or "LAN." A VPN can grow to accommodate more 
users and different locations much easier than a leased 
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line. In fact, scalability is a major advantage that 
VPNs have over typical leased lines. Unlike leased 
lines, where the cost increases in proportion to the 
distances involved, the geographic locations of each 
5 office matter little in the creation of a VPN. 

A well-designed VPN uses several methods for keeping 
connections and data secure. Firewalls provide a strong 
barrier between private networks and the Internet. 
Firewalls can restrict the number of open ports, what 

10 type of packets are passed through, and which protocols 
are allowed through. Encryption is used to encode all 
the data that one computer is sending to another into a 
form that only the other computer will be able to decode. 
Two modes of authentication are used on VPNs: pre-shared 

15 keys and digital signatures, 

Pre-shared key encryption means that each partner in 
a VPN has a secret "key" that it can use to authenticate 
the remote identifier of a VPN. Pre-shared key 
encryption requires that you know which computers will 

20 talk to each other, and that you install the same key on 
each one. 

Digital signature authentication, on the other hand, 
uses a combination of a private key and a public key. 
The private key is known only to your computer while the 

25 public key is given by your computer to any computer that 
wants to communicate securely with it. To decode an 
encrypted message, the receiving computer must use the 
public key provided by the originating computer. Public 
keys are bound to an identity, such as a business or a 

30 user, by using "digital certificates" that are typically 
issued by a trusted third party. 
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The key is based on a hash value. This is a value 
that is computed from a base input number using a hashing 
algorithm. The important thing about a hash value is 
that it is nearly impossible to derive the original input 
5 number without knowing the data used to create the hash 
value. Public keys generally use complex algorithms and 
very large hash values for encrypting. 

On a typical VPN, the authentication of the initial 
connection is accomplished using public key algorithm. 

10 Once the connection is established and authenticated, 
keying material is sent from one computer to the other 
and the connection switches to symmetric encryption, such 
as DES or Triple DES . Symmetric encryption is used 
during data transfer because the amount of time decoding 

15 data is reduced. 

The Internet Protocol Security Protocol (IPsec) 
provides enhanced security features such as strong 
encryption algorithms and comprehensive authentication. 
IPsec has two encryption modes: tunnel and transport. 

20 Tunnel mode tunnels the original packet and builds a new 
IP header, while transport mode inserts the IPsec payload 
between the IP header and the data. Systems that are 
IPsec compliant can take advantage of this protocol. 
Also, all devices negotiate security parameters, but they 

25 must have compatible security policies set up. IPsec 
works well on both Remote-Access and Site-to-Site VPNs. 
IPsec must be supported at both tunnel interfaces to 
work. 

The IPsec protocol can be used in conjunction with 
30 the Internet Key Exchange security protocol (IKE) , This 
protocol provides additional authentication and 
encryption features to the IPsec standard- 
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Many VPNs rely on tunneling to create a private 
network that reaches across the Internet. Essentially, 
tunneling is the process of placing an entire packet 
within another packet and sending it over a network. The 
5 protocol of the outer packet is understood by the network 
and both points, called tunnel interfaces, where the 
packet enters and exits the VPN. Tunneling uses three 
different protocols: (1) carrier protocol: the protocol 
used by the network that the information is traveling 
10 over; (2) encapsulating protocol: the protocol that is 
wrapped around the original data; and (3) passenger 
protocol: the original data (IPX, NetBeui, IP) being 
carried. 

Tunneling has important implications for VPNs. For 
15 example, a packet that uses a protocol not supported on 
the Internet (such as NetBeui) can be placed inside an IP 
packet and sent it safely over the Internet. Or a packet 
that uses a private (non-routable) IP address can be 
placed inside a packet that uses a globally unique IP 
20 address in order to extend a private network over the 
Internet. Tunneling is also necessary for gateways 
because the IP header needs to have the gateway IP 
address in it. 

An analogy of tunneling is having a computer 
25 delivered to you by a courier service. The vendor packs 
the computer (passenger protocol) into a box 
(encapsulating protocol) which is then put on a courier 
truck (carrier protocol) at the vendor's warehouse (entry 
tunnel interface) . The truck (carrier protocol) travels 
30 over the highways (Internet) to your home (exit tunnel 
interface) and delivers the computer. You open the box 
(encapsulating protocol) and remove the computer 
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(passenger protocol) . 

The Internet Protocol Security Protocol (IPsec) is a 
set of open standards. These standards are implemented 
in a variety of different ways by each different 
5 operating system that supports these standards. 
Therefore, a computer system that is initiating a 
communication may implement the Internet Protocol 
Security Protocol in one way while a computer system that 
is a responder computer system may implement IPsec in a 

10 different way. 

In known systems when a system administration needs 
to configure a tunnel between two computer systems that 
implement the IPsec protocol in different ways, the 
system administration must configure the tunnel manually 

15 by directly inputting the various necessary parameters. 
This process of manually configuring the security tunnels 
can become very time consuming, especially in systems 
requiring many different tunnels. 

Therefore, a need exists for a method, system, and 

20 product for automatically configuring an IP security 
tunnel utilizing a standardized security policy 
specification format in computer systems using any one of 
different operating systems. 
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SUMMARY OF THE INVENTION 

A data processing system, method, and product are 
disclosed for automatically configuring IP security 
5 tunnels, A security policy specification format is 

established that is capable of being utilized by any one 
of multiple different operating systems and any one of 
multiple different machine types. The format specifies a 
plurality of different elements that may be used to 
10 define a configuration of an IP security tunnel. 

In order to define an IP security tunnel 
configuration, a system administrator first generates an 
XML file utilizing the elements defined by the standard 
format. This XML file defines the configuration of a 
15 particular IP security tunnel. The configuration of 

multiple IP security tunnels may be compared by comparing 
their respective XML files. 

The XML file may be used by any type of machine type 
and any type of operating system. When the XML file is 
20 processed, it will automatically configure an IP security 
tunnel as defined by the elements included in the file. 

The format includes elements to define the various 
parameters defined by the IPsec protocol and the 
Internet Key Exchange (IKE) protocol. The format 
25 includes elements to define separate IKE and IPsec 
protections. Elements are also included to describe 
remote and local end points, groups, and pre-shared keys. 

When the format is used, tunnels can be configured 
to a large number of endpoints easily, quickly, and 
30 programmatically . 
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The above as well as additional objectives, 
features, and advantages of the present invention will 
become apparent in the following detailed written 
description. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The novel features believed characteristic of the 
invention are set forth in the appended claims. The 
5 invention itself, however, as well as a preferred mode of 
use, further objectives and advantages thereof, will best 
be understood by reference to the following detailed 
description of an illustrative embodiment when read in 
conjunction with the accompanying drawings, wherein: 
10 Figure 1 is a system diagram showing a single 

computer using multiple tunnels to communicate with 
various VPNs; 

Figure 2 is a diagram showing tunnels being created 
between a computer and other computers using VPN 
15 configuration data and certificate data; 

Figure 3 is a database diagram showing tables used 
in configuring tunnels between the computer and other 
computer systems; 

Figure 4 illustrates a high level flow chart which 
20 depicts the creation of a phase 1 tunnel using VPN 
configuration data in accordance with the present 
invention; 

Figure 5 depicts a high level flow chart which 
illustrates the details involved in creating a secure 
25 phase 1 tunnel using the VPN configuration data in 
accordance with the present invention; 

Figure 6 illustrates a high level flow chart which 
depicts the steps performed in using policies to 
communicate through phase 1 and phase 2 processing in 
30 accordance with the present invention; 

Figure 7 depicts a high level flow chart which 
illustrates establishing a standard format to use by any 
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operating system and any machine type to automatically 
configure IP security tunnels in accordance with the 
present invention; and 

Figure 8 illustrates a high level flow chart which 
depicts automatically configuring an IP security tunnel 
using a standard format in accordance with the present 
invention . 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

A preferred embodiment of the present invention and 
its advantages are better understood by referring to the 
5 figures, like numerals being used for like and 
corresponding parts of the accompanying figures. 

The invention is preferably realized using a 
well-known computing platform, such as an IBM RS/6000 
server running the IBM AIX operating system. However, it 

10 may be realized in other popular computer system 

platforms, such as an IBM personal computer running the 
Microsoft Windows operating system or a Sun Microsystems 
workstation running operating systems such as UNIX or 
LINUX, without departing from the spirit and scope of the 

15 invention . 

Figure 1 shows a system diagram of a single computer 
using multiple tunnels to communicate with various 
virtual private networks (VPNs) . Computer system 100 is 
shown using computer network 110, such as the Internet, 

20 to communicate with computers using three VPNs - VPN "A" 
(120), VPN "B" (140), and VPN "C" (160). Three tunnels 
are shown connecting computer system 100 to first 
computer system 130, second computer system 150, and 
third computer system 170. First computer system 130 is 

25 shown as a member of VPN "A" (120), second computer 

system 150 is shown as a member of VPN "B" (140), and 
third computer system 170 is shown as a member of VPN "C" 
(160) . Each of the VPNs may use a different 
authentication means to secure the data traveling between 

30 the computer systems. For example, computers within VPN 
"A" 120 may use a pre-shared key (i.e., a common key 
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shared amongst the computers used to derive encryption 
keys) . VPN "B" 140, on the other hand, may use public 
key encryption to encrypt the data. Finally, VPN "C" 160 
may use digital signatures with digital certificates 
5 verified by a trusted third party, also called a 
"certification authority," or "CA". 

Further each of these computers may be implemented 
using different hardware, i.e. different machine types. 
Each computer system may also be utilizing a different 

10 operating system. 

Figure 2 shows a diagram of tunnels being created 
between a computer and other computers using VPN 
configuration data and certificate data. Computer system 
200 establishes various tunnels used to securely transmit 

15 data to and from other computer systems. Computer 
systems that computer system 200 wishes to securely 
communicate with over a VPN are identified in VPN 
configuration database 210. VPN data 220 contains 
information for connecting with a particular computer 

20 system. Using VPN configuration database 210, any number 
of VPNs can be established between computer system 200 
and other computer systems. Some VPNs use certificate 
data 280 supplied by a trusted third party computer 
system 270. The use of a trusted third party aids in 

25 authenticating users and ensuring that an impostor does 
not take the place of another computer system. 

In the example shown, computer system 200 
establishes tunnel A 235 securely connecting first 
computer system 230 with computer system 200. Likewise, 

30 tunnel B 245 securely connects second computer system 240 
with computer system 200, tunnel C 255 securely connects 
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third computer system 250 with computer system 200, and 
tunnel D 265 securely connects fourth computer system 260 
with computer system 200. Each of these computer 
systems, 230, 240, 250, and 260, have identification 
5 information and authentication information stored in VPN 
configuration database 210. 

Figure 3 shows a database diagram of tables used in 
configuring tunnels between the computer and other 
computer systems. VPN configuration database 300 is 

10 shown with four tables. Endpoints table 310 includes a 
list of configured tunnels between the computer system 
and other computer systems. One end of each endpoint 
identifies the computer system, while the other end of 
the endpoint identifies a remote computer. Each of the 

15 computers included in endpoints table 310 is identified 
with an identifier, such as an address. In addition, 
endpoints table 310 includes IP addresses for the remote 
computer systems. An IP address is an identifier for a 
computer or device on a TCP/IP network. Networks using 

20 the TCP/IP protocol route messages based on the IP 

address of the destination. The format of an IP address 
is a 32-bit numeric address written as four numbers 
separated by periods. Each number can be zero to 255. 
For example, 1.160,10.240 could be an IP address. Within 

25 an isolated network, IP addresses can be assigned at 
random so long as each one is unique. However, 
connecting a private network to the Internet requires 
using registered IP addresses (called Internet addresses) 
to avoid duplicates. The four numbers in an IP address 

30 are used in different ways to identify a particular 

network and a host on that network- Finally, endpoints 
table 310 includes a flag indicating whether a 
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Certificate Revocation List (CRL) is used to check 
whether a given certificate has been revoked. Other 
valid ID types include FQDN, user@FQDN, distinguished 
names, and key IDs. 
5 Endpoints table 310 has relationships with three 

other tables in VPN configuration database 300. Each 
local-remote computer pair included in endpoints table 
310 may have a pre-shared key stored in pre-shared keys 
table 330 or a public key stored in digital certificate 

10 table 340. In some situations, a local-remote computer 
pair may have both a pre-shared key and a public key. 
Finally, a policy from policy table 320 exists for one or 
more set of endpoints determining the access method and 
preference order for connecting the local computer to a 

15 given remote computer. 

Policy table 320 is used to employ a connection 
policy used by a given VPN. Typically, one policy exists 
for each VPN that the local machine uses. Policy table 
320 includes the available secure access methods, such as 

20 pre-shared key and digital certificates, that are 

available in using the VPN. In addition, policy table 
320 includes a preference order for establishing secure 
connections when multiple access methods are available. 
For example, a VPN may prefer using digital certificates 

25 to establish secure connections. However, if the 

computer system is unable to make a secure connection 
using a digital certificate, a pre-shared key method may 
also be available as a second course of action. 

Pre-shared keys table 330 includes a list of common, 

30 or shared, keys for each tunnel pair that uses a 

pre-shared key security method. Computers using a 
pre-shared key have the same key to derive encryption and 
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decryption keys. The pre-shared key is often provided to 
the computer system or the user in a way to reduce the 
chance that the key is misappropriated. For example, a 
pre-shared key may be mailed from a company to a client. 
5 The client then uses the pre-shared key to establish 
secure communications with the company computer system. 
Different pre-shared keys are used for each combination 
of computer systems. In this manner, if one pre-shared 
key is compromised only data at the two systems using 

10 that key are in jeopardy. 

Digital certificate table 340 includes a list of 
certificates (Public Keys) for each tunnel pair that uses 
digital certificates to secure communications. In 
addition, digital certificate table 340 may include 

15 signing digital certificate keys used for Certificate 
Revocation List servers to determine whether a given 
certificate has been revoked. Public key encryption uses 
a private key to encrypt information destined for a given 
computer system. The receiving computer system deciphers 

20 the information by using the sender's public key. The 
local computer system's private key is also included in 
digital certificate table 340. 

Figure 4 shows a flowchart of the creation of a 
tunnel using VPN configuration data. Processing 

25 commences at 400 whereupon a remote computer identifier 
is retrieved (input 405) corresponding to a remote 
computer to be connected in a VPN with the current 
computer system. The remote computer ID is typically 
received from a user command or IKE message. The remote 

30 computer ID is retrieved for both the initiator and the 
responder. The local-remote endpoints pair corresponding 
to the remote computer system identifier and the local 
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computer identifier is selected from the endpoints table 
(step 410) . The ID Rules List links the local-remote 
endpoints pair to a security policy name that is used in 
selecting the security policy (see step 440) . A 
5 determination is made as to whether the endpoints pair 
was found (decision 415) . If the pair was not found, 
decision 415 branches to "no" branch 420 whereupon an 
error is reported that the user needs to configure a 
tunnel with the remote computer system before the tunnel 
10 can be used (step 425) and processing terminates (end 
430). Additionally, step 425 could invoke a 
configuration screen allowing the user to configure the 
fj tunnel with the remote computer by supplying the needed 

access information, 
in 15 If the pair was found in the endpoints table, 

3 decision 415 branches to "yes" branch 435 whereupon a 

n policy corresponding to the local-remote pair is selected 

from the policy table (step 440) . The policy includes a 
H proposal list with separate initiator and responder 

?1 20 proposals. Proposals have general characteristics, like 
3 lifetimes and transform names. Transforms include 

specific encryption algorithms, hash algorithms, and 
authentication methods being proposed. A determination 
is made as to whether a corresponding policy was found 
25 (decision 445) . If a corresponding policy was not found, 
decision 445 branches to "no" branch 450 whereupon a 
default policy is used (step 455) . For example, a 
default policy could be used to use a digital certificate 
(if available), before attempting to use any available 
30 pre-shared keys. If the policy is found, decision 445 
branches to "yes" branch 460. 
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The initiator proposes one or more authentication 
methods to the responder in the order of initiator's 
preference (predefined process 465, see Figure 6 for 
further details). The initiator receives the responder 's 
5 selection of an authentication method (step 470) . A 

determination is made as to whether an error occurred in 
receiving the responder 's selection (decision 475). If 
an error occurred, decision 475 branches to "yes" branch 
480 whereupon processing terminates at 485. On the other 

10 hand, if an error did not occur, decision 475 branches to 
"no" branch 488 whereupon a secure phase 1 tunnel is 
created between the initiator and the responder for 
setting up the phase 2 negotiations to select security 
choices for data traffic (predefined process 490, see 

15 Figure 5 for further details) . Predefined process 490 

includes validating IDs, certificates, or pre-shared keys 
as well as checking the "liveliness" of the connection 
that the other computer matches the retrieved endpoint 
computer description during the entire conversation. 

20 After predefined process 490, create phase 1 tunnel 
processing terminates at 495. 

Figure 5 shows a flowchart of the details involved 
in creating a secure tunnel using the VPN configuration 
data. Processing commences at 500 whereupon the local 

25 computer connects to the remote computer using the 
selected authentication method (step 505) . A 
determination is made as to whether the authentication 
method uses a digital certificate (decision 510) . If the 
authentication method uses a digital certificate, 

30 decision 510 branches to "yes" branch 545 whereupon 
certificate processing commences. 
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On the other hand^ if the access method does not use 
a digital certificate^ decision 510 branches to "no" 
branch 515 whereupon a pre-shared key corresponding to 
the remote computer system is selected from the 
5 pre-shared key table (step 520) . A determination is made 
as to whether the pre-shared key is found (decision 525) . 
If the pre-shared key is not found, decision 525 branches 
to "no" branch 526 whereupon an error is returned at 590. 
If the pre-shared key is found, decision 525 

10 branches to "yes" branch 528 whereupon the local machine 
attempts to connect to the remote machine using the 
selected pre-shared key (step 530) . A determination is 
made as to whether the local machine successfully 
connected to the remote machine (decision 535) . If the 

15 local machine did not successfully connect to the remote 
machine, decision 535 branches to "no" branch 536 
whereupon an error is returned at 590. On the other 
hand, if the local machine successfully connects to the 
remote machine, decision 535 branches to "yes" branch 538 

20 whereupon processing returns to the calling routine 
(return 595, see Figure 4) . 

Figure 6 is a flowchart showing steps performed in 
using policies to communicate through phase 1 and phase 2 
processing. 

25 In Phase 1, Initiator 600 commences by proposing 

(step 610) specifications, authentication methods, and 
encryption algorithms to responder 605. Responder, in 
turn, receives the proposal (step 615) and selects an 
authentication method, specifications, and an encryption 

30 algorithm from the proposal and returns the selection to 
the initiator (step 620) . Responder expects to receive 
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these specifications in a DTD file which follows the 
standard format, as depicted in Figure 7. The initiator 
receives the responder's selection (step 625). A 
Dif f ie-Hellman key exchange is performed between the 
5 initiator and responder (steps 640 and 645) and 

authentication data is exchanged depending upon the 
selected authentication method. 

Each party;, the initiator and the responder, 
establishes an Internet Security Association and Key 

10 Management Protocol (ISAKMP) Security Association (steps 
650 and 655) to use in securing information sent between 
the computer systems. In Phase 2 processing, each system 
creates IPsec Security Associations for securing data 
traffic sent between the systems by negotiating one or 

15 more Security Associations and the systems exchange IP 

addresses by using phased IDs and policies (steps 660 and 
670, for further details about IDs and policies see 
Figure 7) . After the IDs have been exchanged and a 
security association has been negotiated, each system 

20 sends and receives protected data traffic using the 

established policies and profiles (steps 670 and 675) . 

Figure 7 depicts a high level flow chart which 
illustrates establishing a standard format to use by any 
operating system and any machine type to automatically 

25 configure IP security tunnels in accordance with the 
present invention. The process starts as depicted by 
block 700 and thereafter passes to block 702 which 
illustrates establishing a standard format as a document 
type definition (DTD) file for specifying IP security 

30 tunnels. A DTD file defines a collection of elements 

that may appear in an XML file. Next, block 704 depicts 
including a root element in the standard. The following 
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is an example of a root element: 

< ! ELEMENT AIX__VPN ( ( IKEProtection | IKEGroup | IKETunnel | 

IKEPre-sharedKey | IPSecProposal | 

IPSecProtection | IPSecTunnel) +) > 
5 Any combination of IKEProtection, IKEGroup, 
IKEPre-sharedKey, IKETunnel, IPSecProposal, 
IPSecProtection, IPSecTunnel elements may be included in 
the root element. Any number of occurrences of each 
element may be included in the root element. 
10 Block 706 illustrates including a protection element 

in the standard which includes a listing of IKE 
transforms. The following is an example of a protection 
element : 

<! ELEMENT IKEProtection ( IKETransf orm+) > 
15 <!ATTLIST IKEProtection 

IKE_ProtectionName ID #REQUIRED 

IKE_Role ( Initiator | Responder | Both | Neither) ''Both'' 
IKE__XCHGMode (Main 1 Aggressive ) "Main" 
IKE_KeyOverlap CDATA ^^5" 
20 IKE_Flags_UseCRL (Yes | No) "No" 

IKE_ResponderKeyRefreshMaxMinutes CDATA ^M80" 
IKE_ResponderKeyRefreshMinMinutes CDATA ''15" 
IKE_ResponderKeyRefreshMinKB CDATA #IMPLIED 
IKE_ResponderKeyRefreshMaxKB CDATA #IMPLIED 

25 > 

Thereafter, block 708 depicts including a transform 
element in the standard. A list of transform elements 
will be used for phase 1 security associations 
negotiations. The following is an example of a transform 
30 element: 

<! ELEMENT IKETransform EMPTY> 
< ! ATTLIST IKETransform 



21 

Docket No. AUS920010449US1 



IKE AuthenticationMethod (Preshared_key I 



RSA_signatures) 



IT 



Preshared_key 



IKE_Encryption (DES-CBC 1 3DES-CBC) "3DES-CBC 
IKE_Hash (SHA I MD5) "SHA" 
IKE_DHGroup (1 I 2 ) "2" 
IKE_KeyRefreshMinutes CDATA "480" 



IT 



5 



> 



The process then passes to block 710 which 



10 illustrates including a group element in the standard. 
This element can contain multiple identification 
elements. The purpose of this element is to allow the 
same protections and policies to be shared by multiple 
IDs. The following is an example of a group element: 

15 <! ELEMENT IKEGroup (IKEID+)> 
<!ATTLIST IKEGroup 



Next, block 712 depicts including an identification 
20 element in the standard- This element includes 

identification types that can be used by both phase 1 and 



types are valid in both phases. Phase 1 can use ASN1_DN, 
FQDN, User_FQDN, and KEYID. Phase 2 can use IPV4_Subnet, 
25 IPV6_Subnet, IPV4_Address_Range, and IPV5_Address_Range . 
Both phases can use IPV4_Address and IPV6_Address . The 
protocol and port attributes are only valid in phase 2, 
The following is an example of an identification element: 

30 <! ELEMENT IKEID (ASN1_DN 1 FQDN I User_FQDN | 
IPV4 Address I 



IKE_GroupName ID #REQUIRED 



> 



phase 2 tunnels. 



However, not all of the identification 



IPV6 Address | KEYID | IPV4__Subnet | 
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IPV6_Subnet | 

IPV6_Address_Range | 

IPV4_Address_Range) > 
<!ATTLIST IKEID 
5 Protocol CDATA "0" 

Port CDATA "0" 

> 

Thereafter, block 714 illustrates including a tunnel 
element in the standard. This element defines the phase 
10 1 security association endpoints and the IKEProtection 

element to be used for the negotiation. The following is 
an example of a tunnel element: 
<! ELEMENT IKETunnel ( IKELocalldent ity , 
IKERemoteldentity) > 
15 <!ATTLIST IKETunnel 

IKE_TunnelName ID #REQUIRED 
IKE_ProtectionRef IDREF #REQUIRED 
IKE_Flags_MakeRuleWithOptionalIP (Yes I No) "No" 
IKE_Flags_AutoStart (Yes 1 No) "No" 

20 > 

The "MakeRuleWithOptionallP" field specifies whether 
another entry will be put in the rules list using the 
optional IP address specified in the remote identity 
element. If this field is set to "no", more than one 

25 tunnel can be defined using the same optional IP address; 
however, the computer system cannot act as a responder in 
a main mode negotiation with this tunnel. If an optional 
IP address is specified for the local identity element 
when the "MakeRuleWithOptionallP" is set to "no", the 

30 optional IP address will be silently discarded as 
extraneous information for that negotiation type. 
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The process then passes to block 716 which depicts 
including a local identity element and a remote identity 
element in the standard. These elements define the local 
and remote IDs. The following are examples of a local 
5 identity element and a remote identity element: 

<! ELEMENT IKELocalldentity (ASN1_DN | FQDN I User_FQDN | 

IPV4_Address I 
IPV6_Address I KEYID) > 
<! ELEMENT IKERemoteldentity (ASN1_DN I FQDN 1 User_FQDN | 
IQ IPV4_Address | IPV6_Address 

I KEYID I 

IKEGroupRef ) > 
Next, block 718 illustrates including an ID type 
element in the standard. These following are examples of 
15 possible ID type elements which may be included in the 
standard: 

<! ELEMENT IPV4_Address EMPTY> 
<!ATTLIST IPV4_Address 

Value CDATA #REQUIRED 

20 > 

<! ELEMENT IPV4_Subnet EMPTY> 
<!ATTLIST IPV4_Subnet 

IPAddr CDATA #REQUIRED 

Netmask CDATA #REQUIRED 

25 > 

<! ELEMENT IPV4_Address_Range EMPTY> 
<!ATTLIST IPV4_Address_Range 

From_IPAddr CDATA #REQUIRED 

To_IPAddr CDATA #REQUIRED 

30 > 

<! ELEMENT IPV6_Address EMPTY> 
<!ATTLIST IPV6 Address 
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Value CDATA #REQUIRED 

> 

<! ELEMENT IPV6_Subnet EMPTY> 
<!ATTLIST IPV6_Subnet 
5 IPV6_Addr CDATA #REQUIRED 

IPV6__PrefixLength CDATA #REQUIRED 

> 

<! ELEMENT IPV6_Address_Range EMPTY> 
<!ATTLIST IPV6_Address_Range 
10 From_IPV6_Addr CDATA #REQUIRED 

To_IPV6_Addr CDATA #REQUIRED 

> 

<!ELEMENT FQDN ( IPV4_Address | IPV6_Address ) ?> 
<!ATTLIST FQDN 
15 Value CDATA #REQUIRED 

> 

<!ELEMENT User__FQDN { IPV4_Address | IPV6_Address ) ?> 
<!ATTLIST User_FQDN 

Value CDATA #REQUIRED 

20 > 

<! ELEMENT ASN1_DN (IPV4_Address | IPV6_Address ) ?> 
<!ATTLIST ASN1_DN 

Value CDATA #REQUIRED 

> 

25 <!ELEMENT KEYID { IPV4_Address | IPV6_Address ) ?> 
<!ATTLIST KEYID 

Value CDATA #REQUIRED 

> 

The process then passes to block 720^ which depicts 
30 including a reinote pre-shared key ID element in the 

standard. This element is the ID definition for remote 
pre-shared key. The following is an example of a remote 
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pre-shared key ID element: 

<! ELEMENT IKEPresharedRemotelD (PK_ASN1_DN | PK_FQDN | 

PK_User_FQDN | 

PK_IPV4_Address | 

PK_IPV6_Address | 

PK_KEYID) > 

Block 722, then, illustrates including a pre-shared 
key element in the standard. This element is the ID 
definition for the pre-shared key. The following is an 
example of a pre-shared key element: 
<! ELEMENT PK_IPV4_Address EMPTY> 
<!ATTLIST PK_IPV4_Address 

Value CDATA #REQUIRED 

> 

<! ELEMENT PK_IPV6_Address EMPTY> 
<!ATTLIST PK_IPV6_Address 

Value CDATA #REQUIRED 

> 

<! ELEMENT PK_FQDN EMPTY> 
<!ATTLIST PK_FQDN 

Value CDATA #REQUIRED 

> 

<! ELEMENT PK_User_FQDN EMPTY> 
<!ATTLIST PK_User_FQDN 

Value CDATA #REQUIRED 

> 

<! ELEMENT PK_ASN1_DN EMPTY> 
<!ATTLIST PK_ASN1_DN 

Value CDATA #REQUIRED 

> 

<! ELEMENT PK_KEYID EMPTY> 
<!ATTLIST PK KEYID 
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Value CDATA #REQUIRED 

> 

Next, block 724 depicts including an IPsec proposal 
element in the standard. This element includes a list of 
5 IPSec encapsulating security protocol (ESP) protocols 
and/or IPSec authentication header (AH) protocols 
elements. The following is an example of an IPsec 
proposal element: 

<!ELEMENT IPSecProposal ( (IPSecESPProtocol 1 
10 IPSecAHProtocol) +) > 

<!ATTLIST IPSecProposal 

IPSec_ProposalName ID #REQUIRED 

> 

The process then passes to block 726 which 
15 illustrates including an IPsec ESP protocol element in 
the standard. This element defines an IPsec ESP 
protocol. The following is an example of an IPsec ESP 
protocol element: 

<! ELEMENT IPSecESPProtocol EMPTY> 
20 <!ATTLIST IPSecESPProtocol 

ESP_Encryption (ESP_DES | ESP_3DES I ESP_NULL ) 
"ESP_DES" 

ESP_Authentication (HMAC-MD5 1 HMAC-SHA | NONE ) 
"HMAC-SHA" 

25 ESP_EncapsulationMode (Tunnel | Transport ) 

"Tunnel" 

ESP_KeyRefreshMinutes CDATA "60" 
ESP_KeyRefreshKB CDATA #IMPLIED 

> 

30 Thereafter, block 728 depicts including an IPsec 

authentication header protocol element in the standard. 
This element defines an authentication header protocol. 
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The following is an example of an authentication header 
protocol element: 

<! ELEMENT IPSecAHProtocol EMPTY> 
<!ATTLIST IPSecAHProtocol 
5 AH_Authentication (AH_MD5 | AH_SHA ) "AH_SHA" 

AH_EncapsulationMode (Tunnel 1 Transport ) 
"Tunnel" 

AH_KeyRefreshMinutes CDATA "60" 
AH_KeyRefreshKB CDATA #IMPLIED 

10 > 

Next, block 730 illustrates including an IPsec 
protection element in the standard. This element defines 
IPsec protection. The following is an example of an 
IPsec protection element: 
15 <! ELEMENT IPSecProtection EMPTY> 
<!ATTLIST IPSecProtection 

IPSec_ProtectionName ID #REQUIRED 
IPSec_ProposalRefs IDREFS #REQUIRED 
IPSec_Role ( Initiator | Responder | Both | Neither) 

20 "Both" 

IPSec_KeyOverlap CDATA "5" 

IPSec_Flags_UseCommitBit (Yes I No) "No" 
IPSec_Flags_UseLifeSize (Yes | No) "No" 
IPSec_InitiatorDHGroup (0 I 1 I 2 ) "0" 
25 lPSec_ResponderDHGroup (NO_PFS | GR0UP_1 I 

GR0UP_2 I 

GR0UP_1_0R_2 1 
NO_PFS_OR_GROUP_1_OR_2 ) 
"N0_PFS_0R_GR0UP_1_0R_2 " 
30 iPSec_ResponderKeyRefreshMaxMinutes CDATA "120" 

IPSec_ResponderKeyRefreshMinMinutes CDATA "1" 
IPSec_ResponderKeyRefreshMaxKB CDATA #IMPLIED 
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IPSec_ResponderKeyRefreshMinKB CDATA #IMPLIED 

> 

The process then terminates as depicted by block 732. 

Figure 8 illustrates a high level flow chart which 
5 depicts automatically configuring an IP security tunnel 
using a standard format in accordance with the present 
invention. The process starts as depicted by block 800 
and thereafter passes to block 802 which depicts 
generating an XML file under the guidelines of the 

10 standard format defined by the DTD file described in more 
detail in Figure 7. Next, block 804 illustrates 
including elements from the standard as necessary to 
properly configure an IP security tunnel. Thereafter, 
block 806 depicts processing the XML file. Processing 

15 this file automatically configures an IP security tunnel. 
The process then terminates as depicted by block 808. 

Below is an example of an XML file that configures a 
tunnel under the guidelines of the standard. 
<?xml version-"!. 0" ?> 

20 <!DOCTYPE AIX VPN SYSTEM "ike.dtd"> 



<AIX VPN> 



<!-- Define a Phase 1 policy — > 
25 <IKEProtection IKEProtectionName=" IBM_low_CertSig" 

IKEResponderKeyRef reshMinTime=" 300" 
IKEResponderKeyRef reshMaxTime=" 8 1 4 0 0 " > 

<! — Define the transforms underneath this 
30 IKEprotection — > 

<IKETransform AuthMethod="RSASignature" Encrypt="DES" 
Hash="SHA" IKEDHGroup-"!" /> 
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<IKETransf orm AuthMethod="PresharedKey" 
IKEDHGroup-"l"/> 
</IKEProtection> 



5 <! — An example for the group — > 

<IKEGroup IKEGroupName="PlGroup__shruthi"> 
<ASN1_DN 

Value="/C=US/0=IBM/OU=IPSec/CN=shruthi.austin. ibm.com"> 
<IPV4_Address Value=" 9 . 53 . 150 . 11" /> 
10 </ASNl_DN> 

<FQDN Value="shruthi . austin . ibm. cora"> 

<IPV4_Address Value="9 . 53 . 150 . ll"/> 
</FQDN> 

<IPV4_Address Value="9 . 53 . 150 . ll"/> 
15 </IKEGroup> 



<! — Define the phase 1 tunnel — > 
<IKETunnel IKETunnelName="Pl_Apricot" 
IKEProtectionRef="IBM_low_CertSig"> 
20 <IKELocalIdentity> 

<IPV4_Address Value-"9 . 3 . 97 . 138"/> 
</IKELocalIdentity> 
<IKERemoteIdentity> 

<IPV4_Address Value="9 . 3.97. 66" /> 
25 </lKERemoteIdentity> 
</IKETunnel> 



<! — Define the phase 1 Tunnel with remote-id being a 
group name 

30 <IKETunnel IKETunnelName="Pl_Apricot_Group" 

IKEProtectionRef="lBM_low_CertSig"> 
<IKELocalIdentity> 
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<IPV4_Address Value="9 . 3 . 97 . 138"/> 
</lKELocalIdentity> 
<IKERemoteIdentity> 

<IKEGroupRef IKEGroupNameRef ="PlGroup_shruthi" /> 
5 </IKERemoteIdentity> 
</IKETunnel> 

<!-- Specify the preshared keys for the 9.3.97.138 & 
9.53.150.11 
10 <IKEPresharedKey Value= ^ abcd>" ' > 
<IKEPresharedRemoteID> 

<IPV4_Address Value="9. 53. 150. ll"/> 
</IKEPresharedReinoteID> 
</IKEPresharedKey> 

15 

<! — Define a Phase 2 proposal — > 

<IPSecProposal ProposalName="IBM_ESP_tunnel_Proposal"> 
<IPSecProtocol Protocol="ESP" ESP_Encryption="DES" 
20 ESP_Authentication-"HMAC-MD5" 
KeyRefreshTime="288 00"/> 
</IPSecProposal> 

<IPSecProtection 
25 IPSecProtectionName="IBM_ESP_tunnel_policy" 

IPSecInitiatorDHGroup="l" 
IPSecKeyRefreshMinTime="120" 

IPSecKeyRefreshMaxTime-" 81400" 

30 IPSecProposalRefs="IBM_ESP__tunnel_Proposal"/> 
<IPSecTunnel IPSecTunnelName="P2_Apricot" 
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IKETunnelName="Pl_Apricot" 

IPSecProtectionRef="IBM_ESP_tunnel_policy"> 
<IPSecLocalIdentity> 

< I PV4_Addr e s s Value= "9.3.97.138"/> 
5 </IPSecLocalIdentity> 
<IPSecReinoteIdentity> 

<IPV4_Address Value="9, 3. 97 , 66"/> 
</IPSecRemoteIdentity> 
</IPSecTunnel> 

10 

</AIX_VPN> 

In this example, explicit policy and tunnel choices 
are being specified^ namely using RSA signature mode for 
authentication with Diffie Helmann group 1 with local 

15 identity 9.3.97,138 and remote identity 9.3.97.66. In 
this example, the use of DES with HMAC-MD5 and a refresh 
time of 28800 seconds are requested. 

It is important to note that while the present 
invention has been described in the context of a fully 

20 functioning data processing system, those of ordinary 
skill in the art will appreciate that the processes of 
the present invention are capable of being distributed in 
the form of a computer readable medium of instructions 
and a variety of forms and that the present invention 

25 applies equally regardless of the particular type of 
signal bearing media actually used to carry out the 
distribution. Examples of computer readable media 
include recordable-type media, such as a floppy disk, a 
hard disk drive, a RAM, CD-ROMs, DVD-ROMs, and 

30 transmission-type media, such as digital and analog 

communications links, wired or wireless communications 
links using transmission forms, such as, for example. 
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radio frequency and light wave transmissions. The 
computer readable media may take the form of coded 
formats that are decoded for actual use in a particular 
data processing system. 
5 The description of the present invention has been 

presented for purposes of illustration and description;, 
and is not intended to be exhaustive or limited to the 
invention in the form disclosed. Many modifications and 
variations will be apparent to those of ordinary skill in 

10 the art. The embodiment was chosen and described in 
order to best explain the principles of the invention^ 
the practical application, and to enable others of 
ordinary skill in the art to understand the invention for 
various embodiments with various modifications as are 

15 suited to the particular use contemplated. 



